It is desirable to provide efficient and cost effective processes for generating queries to a data base management system. In today's world of Relational Data Base Management Systems (RDBMS), data bases can store objects and such objects can invoke other objects. Processes for invoking such objects involve invoking procedures which may themselves invoke other procedures to several levels. This nested complexity makes the debugging and testing of such objects very time consuming and machine inefficient.
In the past, many attempts have been made to automate the process of generating the complete dependencies of programs and to use it for compiling and debugging code. One such attempt, involved binding together pre-compiled subroutines to form a complete host procedure object code, as described in U.S. Pat. No. 4,330,822 titled “Recursive System and Method for Binding Compiled Routines”. Another such attempt, involved reducing the compilation time of modules using one level of module dependencies, as described in U.S. Pat. No. 5,586,328 titled “Module Dependency based Incremental Compiler and Method.” Yet another attempt, involved generating complementary source code to resolve external dependencies of program units to facilitate unit testing, as described in U.S. Pat. No. 6,651,111 titled “Method and Apparatus for producing a software test system using complementary code to resolve external dependencies”. Yet another attempt, involved building an object oriented software program using compiler generated direct dependency information described in U.S. Pat. No. 5,758,160 titled “Method and apparatus for building a software program using dependencies derived from software component interfaces”. In all of these cases only the direct dependencies of the modules concerned are used. In a database programming environment, spending an inordinate amount of time finding the dependencies of program units using a compiler is undesirable, since that information is directly available from the database catalog. Many other U.S. patents describe various debugging and testing systems but none of these which is known to Applicant provides the method and system of the present invention for automatically generating the complete dependencies necessary to debug code objects.
It would be advantageous to have a method for automatically generating debug versions of a subprogram and all its dependencies. The method should allow fixing coding errors much faster by eliminating the need for generating debug versions of all dependent subprograms in a manual fashion. The method should also allow detecting potential runtime errors, before the subprogram is debugged or executed. This would allow the elimination of some of the run time errors that can be very hard to detect in a production environment. The method should also allow programmers to visualize a graphic representation of the complete dependencies of subprograms. The method should also allow programmers to visualize INVALID database objects in the dependency graph. The method should also allow visually identifying cyclic dependencies. This would eliminate the need for programmers spending time figuring out the actual dependencies, the nature of such dependencies and the validity of such dependent objects. This process involves a combination of browsing the source code and looking up the database catalog for specific dependency information. This manual process can be exhaustive, since multiple levels of dependencies are prevalent in database development environments.
For example, the technical problem can be appreciated with the following additional information:
PL/SQL is a complex language, that allows complex inter-dependent code to be developed. Code modules in PL/SQL can reside in separate library units that reference one another. There are four main types of library units:                1. Packages are true libraries that can include one or more stored procedures and one or more functions. Each of those objects can be public or private. Public objects (exposed in the package spec) can be invoked from other library units. Private objects can be invoked internally within the package. Each object (procedure or function) can invoke other objects within the package or external to it.        2. Stored procedures are stored objects that include only one callable module. Code in a procedure can invoke external objects.        3. Functions are stored objects that include only one Callable module. Code in a function can invoke external objects. Functions differ from procedures by returning a value.        4. Triggers are stored objects that are fired by the database engine when various events occur. Triggers can invoke external objects.Oracle8™ also has Types which are abstract data types that can hold data members and member functions.        
The debug process involves an object and all its dependencies. If a logical problem exists with a value returned or set by a called object, then the coding error might exist in either the called object itself, or one of the called objects. A true debugger should let the developer step through the code traversing dependencies at will, without any special effort. The level of complexity in large applications can easily reach 5 to 10 levels of dependency and the dependency tree can include hundreds of objects.
The alternative for the debugger automatically detecting all the dependencies is for the user to manually analyze the dependencies for the objects and then perform a process that alters all those objects to debug mode, so that they can be debugged. In the example mentioned above, with hundreds of dependent objects this process is tedious and time-consuming.
Alternatively, users can compile all their objects in debug mode, but this again is not optimal, since upon completion of the debug phase they will have to re-compile everything again (for production). Then, for every bug discovered later, the same process is required.
Some RDBMS try to provide assistance in handling these problems. For example, Oracle provides the ‘connect by’ clause to generate an implicit tree as the result of SQL query. This method of querying could be applied to provide a partial solution to the problem of generating the complete dependency tree of a stored code object. The method can only provide a partial solution because of the way some of the Oracle code objects behave. Specifically, packages are implemented in Oracle as two distinct code objects—a package specification and a package body. Applying the ‘connect by’ clause above will result in a tree that will contain dependencies of all the package specifications in the dependency tree but not of the corresponding package bodies. A variation of the ‘connect by’ clause that also tracks package body dependencies cannot be constructed because SQL does not provide a way of saying not to connect any further, if a condition is satisfied—i.e. to prevent infinite recursion in the dependency tree, it is imperative to support a way by which, if a dependency already occurs in the tree in the parent path, we should not proceed to get the dependency of the object again.
The present invention is an efficient and effective solution to the technical problem of retrieving all object dependencies from obects stored in a RDBMS. The solution to this technical problem developed by applicants uses a query that is called recursively. An array is used to track the parents so that the graph can be reconstructed. At each step, it is determined whether the dependency already occurs in the graph. If it occurs, the recursion is stopped.